AWS ParallelCluster 追加EBSマウント設定

AWS ParallelCluster 追加EBSマウント設定

Clock Icon2020.10.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ParallelClusterに追加EBSをマウント

  • AWS ParallelClusterはAWSがサポートする、HPCクラスターの管理ツールです。
  • PallelClusterの共有ストレージとしてヘッドノード(ジョブスケジューラ)のEBSを利用できます。
  • ヘッドノードに追加EBSをアタッチし、取り回しの良い柔軟なParallelCluster管理の設定を紹介します。

なにが嬉しいのか

クラスターのライフサイクルと標準NFSマウントからみていきます。

pcluster createでクラスターを作成します。ヘッドノードにはルートデバイスボリュームとは別にNFSマウント用のEBSが作成されます。このEBSのサイズはデフォルトは20GBです。ParallelClusterの設定ファイルでサイズを指定できます。そして、ヘッドノードのNFS用のEBSは共有されコンピュートノードからアクセスできます。

運用していくなかでNFSマウントの共有ディレクトリをよく利用し容量不足になってきたとしましょう。そうしたらヘッドノードのEBSのボリュームを拡張すればいいですよね。残念ながらParallelCluster 2.9.1(現時点での最新)ではヘッドノードのEBSサイズ変更はpcluster updateコマンドからはできません。マネジメントコンソールから直接EBSを弄るなど外部から手を入れればもちろん変更は可能です。しかし、ParallelClusterのクラスター管理の視点から見ると不整合起きるため推奨できません。

回避策のひとつとしてNFSマウントされる領域のEBSを単独で作成して、クラスターのヘッドノードにアタッチさせます。

クラスター作成時に単独で作成したEBSをヘッドノードへアタッチできます。この追加した左側の単独のEBSをNFSマウントの領域としてコンピュートノードに提供します。注意して頂きたいのはクラスター新規作成時ではないと追加のEBSをアタッチできません。

このようにNFSマウント用のEBSを別に設けることにより、クラスターのライフサイクルと切り離してNFSマウントの領域を管理できます。

追加した単独のEBSはクラスター管理とは関係ないため、従来通りのEBSのサイズ拡張や、EBSのタイプ変更がマネジメントコンソールなどから問題なくできます。

クラスターの設定例

作業の流れ

  1. 先にアタッチ用のEBSを作成
  2. ParallelClusterの設定ファイル編集
  3. クラスター新規作成

検証環境構成

項目
OS CentOS7
ジョブスケジューラ Slurm
ParallelClusterバージョン 2.7

EBS作成

説明の都合、AWS CLIで作成しました。マネジメントコンソールでもEBSを作成してVolumeIdを確認できればOKです。

10GBのEBSを作成します。実行結果からVolumeIdvol-xxxxxxxxxを確認します。

aws ec2 create-volume \
    --region ap-northeast-1 \
    --availability-zone ap-northeast-1a \
    --encrypted \
    --volume-type gp2 \
    --size 10 \
    --tag-specification 'ResourceType=volume,Tags=[{Key=Name,Value=test-parallelcluster-add-master}]'

実行結果

{
    "AvailabilityZone": "ap-northeast-1a",
    "CreateTime": "2020-10-06T04:03:33+00:00",
    "Encrypted": true,
    "Size": 10,
    "SnapshotId": "",
    "State": "creating",
    "VolumeId": "vol-0e453e8aee6ab4d35",
    "Iops": 100,
    "Tags": [
        {
            "Key": "Name",
            "Value": "test-parallelcluster-add-master"
        }
    ],
    "VolumeType": "gp2"
}

検証用コンフィグ

構築する環境に合わせて適時変更してください。とくに下記の項目は環境に依存します。

  • aws_region_name
  • key_name
  • vpc_id
  • master_subnet_id
  • compute_subnet_id

EBSアタッチ設定のポイント

クラスターセクション([cluster hogehoge]配下)にebs_settingsを追加します。

# Enable EBS Setting
ebs_settings = external1

EBSセクション([ebs hogehoge]配下)に先ほど作成したEBSのVolumeIdを入力します。shared_dirはマウント先のパスです。この場合/sharedに追加したEBSがアタッチされ、コンピュートノードの共有されます。

[ebs external1]
# EBS Setting
ebs_volume_id = vol-0e453e8aee6ab4d35
shared_dir = shared

設定ファイル全文

[aws]
aws_region_name = ap-northeast-1

[global]
cluster_template = default
update_check = true
sanity_check = true

[aliases]
ssh = ssh {CFN_USER}@{MASTER_IP} {ARGS}

[cluster default]
key_name = sandbox-key
base_os = centos7
scheduler = slurm
vpc_settings = custom

# Instance Type
master_instance_type = m5.large
compute_instance_type = c5.large

# Use Spot Instance
cluster_type = spot

# Use Placemant Group
placement = compute
placement_group = DYNAMIC

# Cluster Size
maintain_initial_size = true
initial_queue_size = 1
max_queue_size = 4

# Enable EBS Setting
ebs_settings = external1

# Enable CloudWatchLogs
cw_log_settings = cluster_log

# Tag
tags = { "Name" : "EBS-Cluster-v27" }

[vpc custom]
# VPC Setting
vpc_id = vpc-04dcdf74763d5c39d
master_subnet_id = subnet-04c8f3243a402645c
compute_subnet_id = subnet-03e507e27d135a555
use_public_ips = true

[ebs external1]
# EBS Setting
ebs_volume_id = vol-0e453e8aee6ab4d35
shared_dir = shared

[cw_log cluster_log]
# CloudWatchLogs Setting
enable = true
retention_days = 7

クラスター作成

pcluster createでクラスターを作成します。

> pcluster create cluster-ebs-v27 -c v27-EBS-config
Beginning cluster creation for cluster: cluster-ebs-v27
Info: There is a newer version 2.9.1 of AWS ParallelCluster available.
Creating stack named: parallelcluster-cluster-ebs-v27
Status: parallelcluster-cluster-ebs-v27 - CREATE_COMPLETE
MasterPublicIP: 54.250.73.238
ClusterUser: centos
MasterPrivateIP: 10.1.10.184

クラスターの構成確認

ヘッドノード

予定どおり10GBのディスクが/sharedにマウントされています。

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  3.7G     0  3.7G   0% /dev
tmpfs          tmpfs     3.7G     0  3.7G   0% /dev/shm
tmpfs          tmpfs     3.7G   17M  3.7G   1% /run
tmpfs          tmpfs     3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/nvme0n1p1 xfs        25G   12G   14G  47% /
/dev/nvme1n1   ext4      9.8G   37M  9.2G   1% /shared
tmpfs          tmpfs     753M     0  753M   0% /run/user/1000

/shared以外にもいろいろ共有しています。

$ cat /etc/exports
/shared 10.1.0.0/16(rw,sync,no_root_squash)
/home 10.1.0.0/16(rw,sync,no_root_squash)
/opt/intel 10.1.0.0/16(rw,sync,no_root_squash)
/opt/slurm 10.1.0.0/16(rw,sync,no_root_squash)

/sharedディレクトリにヘッドノードからテストファイル(written_by_headnod.txt)を置いてみます。

$ touch /shared/written_by_headnode.txt
$ ll /shared/
total 16
drwx------ 2 root   root   16384 Oct  6 04:19 lost+found
-rw-rw-r-- 1 centos centos     0 Oct  6 04:36 written_by_headnode.txt

コンピュートノード

ヘッドノードからコンピュートノードのプライベートIPを確認してヘッドノードからコンピュートノードへSSH接続が楽です。

$ sinfo -s
PARTITION AVAIL  TIMELIMIT   NODES(A/I/O/T)  NODELIST
compute*     up   infinite          0/1/0/1  ip-10-1-21-121
$ ssh centos@10.1.21.121

今回のヘッドノードのプライベートIPは10.1.10.184です。NFSでコンピュートノードにマウントされていることが確認できます。

$ df -hT
Filesystem                                                Type      Size  Used Avail Use% Mounted on
devtmpfs                                                  devtmpfs  1.8G     0  1.8G   0% /dev
tmpfs                                                     tmpfs     1.8G     0  1.8G   0% /dev/shm
tmpfs                                                     tmpfs     1.8G   17M  1.8G   1% /run
tmpfs                                                     tmpfs     1.8G     0  1.8G   0% /sys/fs/cgroup
/dev/nvme0n1p1                                            xfs        25G   12G   14G  47% /
ip-10-1-10-184.ap-northeast-1.compute.internal:/home      nfs        25G   12G   14G  47% /home
ip-10-1-10-184.ap-northeast-1.compute.internal:/opt/intel nfs        25G   12G   14G  47% /opt/intel
ip-10-1-10-184.ap-northeast-1.compute.internal:/shared    nfs       9.8G   36M  9.2G   1% /shared
ip-10-1-10-184.ap-northeast-1.compute.internal:/opt/slurm nfs        25G   12G   14G  47% /opt/slurm
tmpfs                                                     tmpfs     355M     0  355M   0% /run/user/1000

コンピュートノードからエクスポートしているディレクトリはありませんでした。

$ cat /etc/exports

ヘッドノードから書き込んだファイルをコンピュートノードで確認できました。

$ ll /shared
total 16
drwx------ 2 root   root   16384 Oct  6 04:19 lost+found
-rw-rw-r-- 1 centos centos     0 Oct  6 04:36 written_by_headnode.txt

コンピュートノードからテストファイル(written_by_comnode.txt)を書いてみます。

$ touch /shared/written_by_comnode.txt
$ ll /shared
total 16
drwx------ 2 root   root   16384 Oct  6 04:19 lost+found
-rw-rw-r-- 1 centos centos     0 Oct  6 04:43 written_by_comnode.txt
-rw-rw-r-- 1 centos centos     0 Oct  6 04:36 written_by_headnode.txt

一応ヘッドノードから確認

ヘッドノードからコンピュートノードで書き込んだファイルを確認できます。ヘッドノードに別途追加した10GBのEBSをコンピュートノードに共有して利用できることが確認できました。

$ ll /shared
total 16
drwx------ 2 root   root   16384 Oct  6 04:19 lost+found
-rw-rw-r-- 1 centos centos     0 Oct  6 04:43 written_by_comnode.txt
-rw-rw-r-- 1 centos centos     0 Oct  6 04:36 written_by_headnode.txt

おわりに

ヘッドノードと、コンピュートノード間の共有方法は各種あります。デフォルトで提供されているのがヘッドノードのEBS共有です。その他ストレージを使う予定がなく、クラスターの再構築が難しい環境ですと今回のように共有用のEBSを外だしにしてクラスターを作成すると取り回しが良くなるかと思います。最初に低容量のEBSをマウントしておく分にはランニングコストも余り気になりませんし。

クラスターにEFSをマウントする方法はこちらで紹介しております。

以上、コンサル部の大村@網走でした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.